home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re ODF 2.9 < prev    next >
Encoding:
Internet Message Format  |  1996-07-01  |  2.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF 2
  2. Sent:        6/28/96 9:46 AM
  3. Received:    7/1/96 8:34 AM
  4. From:        Troy Gaul, tgaul@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >I can appreciate this position. I don't blame you for wanting to use the
  9. >tools you are familiar with to develop for multiple platforms. However, if
  10. >we want ODF to succeed and gain industry-wide acceptance, we have to make
  11. >sure that it isn't perceived as a Mac-bigoted framework. Once OpenDoc for
  12. >Windows ships, we intend to bring the Windows version of ODF up to parity
  13. >with the Macintosh version, and support the popular native toolset(s) on
  14. >the Windows platform.
  15.  
  16. As has been mentioned briefly by Henri earlier, it is not necessary to go 
  17. entirely one way or the other with Direct-to-SOM support.  The approach 
  18. of adding DTS support to ODF should be to do it in such a way that its 
  19. use is controlled by a compiler flag.
  20.  
  21. This would allow creating a part as today, by compiling the framework and 
  22. parts of the OS and Foundation layers into the part itself.
  23.  
  24. There would have to be a number of API changes to ODF to accomplish this 
  25. (as DTS has certain limitations, like no overloading, etc).  Also, care 
  26. would have to be taken to make sure that certain things were handled well 
  27. -- for instance, you'd probably want the FW_CPoint and several other 
  28. classes to still be C++ objects or at least C++ wrappers to SOM objects 
  29. so they could use operator overloading, etc.
  30.  
  31. There are several benefits to a SOM version of ODF. There will be more 
  32. sharing of code and therefore a smaller overall memory footprint (when 
  33. there are multiple ODF parts running), really small parts become 
  34. possible, there are opportunities for such things as writing parts in 
  35. Java that are subclasses of ODF (with a Java that has SOM support), and 
  36. so on.
  37.  
  38. _troy
  39.  
  40. ......................................................................
  41.  Troy Gaul                                            tgaul@apple.com
  42.  Apple Computer, Inc.                               OpenDoc Partsmith
  43.  
  44.